\subsection{Motivating Example}
\label{sec:MotivatingExample}



The motivating example is inspired from a real case study of a hospital, where regulations for managing the work of physicians became necessary after frauds and anomalies were detected by an external audit. Doctors receive patients for consultations, but all their actions are recorded in patient files to keep track of the medication and the medical exams prescribed. 


Figure \ref{fig:example-code} depicts a simplified \textsc{Uml} class diagrams representing the Java code for the application: The figure shows the classes \texttt{Doctor}, \texttt{Patient} and \texttt{File} and \texttt{Report}, all connected to the \texttt{MedicalServer}. The \texttt{MedicalServer} centralizes and coordinates all operations (in particular, operations on data bases, not depicted here). The security policy initially consists of the following rules: 

\begin{small}
\begin{enumerate}[\textsf{R}1:]
	\item A doctor can only access the medical files of the patients he's treating;
	\item A doctor should fill a monthly follow-up report for each of his patients;
	\item If he does not submit this report, then he has to justify his action by sending a ``violation of duty'' report;
	\item Meanwhile, his access to certain administrative files are suspended;
	\item A doctor has to delete patients' medical file within two years;
	\item Each time a medical file is created for a patient, it has to be stored encrypted at most one minute after its creation.
\end{enumerate}
\end{small}



%To illustrate and motivate our approach. Consider the following security requirements:
%
%\begin{itemize}
%\item $R_1$: A doctor is allowed to access his patients' private files,
%\item $R_2$: A doctor should fill a monthly follow-up report for each of his patients,
%\item $R_3$: If a doctor does not submit a follow-up report, then he must submit a violation of duty report. 
%\item $R_4$: Meanwhile, the doctor's access to certain administrative files may be temporarily suspended.
%\item $R_5$: A doctor has to delete sensitive patients' files within two years;
%\item $R_6$: If a doctor creates a new file for a sensitive patient, the file has to be stored encrypted at most one minute after its creation.
%\end{itemize}
%

%The correct specification and enforcement of the security policy above presents several challenges: the policy specifies permissions ($R_1$), prohibitions ($R_4$) and obligations ($R_2$ and $R_3$). Therefore, a security model should be {\it expressive} enough to cover these different rule types. The requirements are also {\it abstract} i.e. they do not exactly specify their representation in their enforcement environment. This is desirable to enable a simple and intuitive expression and interpretation of the policy. In other words, one should not worry about the low-level implementation details when defining the policy.
%There is also a {\it separation} between the policy from the business logic, i.e. the policy does not depend of the implementation of the system functionalities. Furthermore, rules $R_3$ and $R_4$ define rules which depend of compliance with other rules, namely the ability of a doctor to correctly fulfill his obligations. We call the aforementioned concerns {\it design-time} requirements since they should be satisfied by the security design model, i.e. their expression should be possible using the model.

%The satisfaction of these design-time elements raises other {\it runtime} requirements: when a policy rule is defined abstractly, then it may still be necessary to link the elements of the rule to their concrete counterparts in the target where the policy is enforced at runtime. For example, consider %an abstract policy entity of {\it role} such as {\it doctor}. An example of a concrete policy entity is a {\it subject} such as {\it John} who may be a {\it doctor}. Policies are specified over abstract policy entities (objects) to simplify policy specification, interpretation and reuse. However, a policy applies for concrete entities. For example, consider 
%an obligation for a {\it doctor} to send a monthly follow-up report. This obligation is defined for the {\it abstract} role {\it doctor}, it will however apply or be activated for a {\it concrete} subject {\it John} if {\it John} is a {\it doctor}. 

%It is also possible that new subjects become or seize to be doctors at runtime. Thus, although it is desirable that policies be defined abstractly, it is necessary to ensure a clear {\it traceability} link between policy entities and the concrete entities at runtime. Reciprocally, requirements may change at runtime due to a change in regulatory or internal mandates. For example, after a change in internal policies or regulations, a doctor may become obliged to submit a follow-up report on a weekly-basis instead of monthly. In this case, policy enforcement should be adapted to reflect this {\it runtime update} of security rules. Another reason to update policies at runtime is to react to policy violations such as specified in $R_3$ and $R_4$. The enforcement of reaction policy rules such as revocation of a doctor's access to some files if he does not fulfill his obligation to submit a patient's follow-up report, requires {\it violation monitoring} capabilities and {\it reaction} capabilities to such violations.


\comments{

To address the requirements presented in the previous section, we propose a MDS approach that is based on Figure~\ref{figure_approach}. 

\begin{figure}
\center
\includegraphics[width=10cm, height=6cm]{Approach4.pdf} 
\caption{Approach Overview}
\label{figure_approach}
\end{figure}

\noindent In the figure, the target architecture and policies specifying security requirements are specified using two separate DSLs to satisfy the separation of concerns. To enable an abstract specification of requirements, we distinguish between {\it abstract} and {\it concrete} policy entities. An example of an abstract policy entity is a {\it role} such as {\it doctor}. An example of a concrete policy entity is a {\it subject} such as {\it John} who may be a {\it doctor}. Policies are specified over abstract policy entities (objects) to simplify policy specification, interpretation and reuse. However, a policy applies for concrete entities. For example, consider an obligation for a doctor to send a monthly activity report. This obligation is defined for the role {\it doctor}, it will however apply or be activated for a subject {\it John} if {\it John} is a {\it doctor}. Similarly, a target, for example a Java application, has abstract and concrete entities such as {\it classes} and {\it instances} respectively. For this reason, we consider two types of assignments to link policy and target entities, namely {\it static} and dynamic {\it contextual} assignments to link policy objects to their counterparts in the target. Contextual assignment (as opposed to static assignments) consider the {\it application state} when objects are linked and enable therefore the support of fine-grained contextual policies. %For this reason, we consider linking targets and policies in two ways. %A set of {\it abstract mapping rules} links the abstract entities of policies and targets and another set of {\it concrete mapping rules} links concrete entities at runtime. 

To enforce and monitor policy compliance, we consider a Policy Enforcement Point (PEP) - Policy Decision Point (PDP) architecture. The PEP monitors the target and intercepts sensitive calls according to the abstract mapping rules. On the other hand, the PDP evaluates the policy and monitors policy compliance according to the assignment rules. In the following, we first present our DSL for {\it security@runtime}, explain each of its elements and show how it fulfills the requirements of abstraction, expressiveness, traceability, violation monitoring and reaction and runtime update.
}

